If you have any suggestions or bugs, please feel free to comment on https://forum.makecode.com/ or https://github.com/microsoft/pxt. We're still in the early stages with Arcade so feedback is especially useful.

What's your product?

* Our server code isn't open source, but it's basically just a node app serving a SPA. Everything is client side. Works offline too.

I worked on video games for the past few years and saw many less technical colleagues empowered by tools like Unreal Engine's Blueprint (https://docs.unrealengine.com/en-us/Engine/Blueprints). I thought that the same paradigm may apply more widely but the visual languages used outside of games weren't really hitting the mark.

Devev is a framework for creating visual programming languages. They are supported through extensions. For launch I'm working on an extension which parses TS types and allows you to use the existing code in nodes. That's what you'll see in my image above. This will allow early users to tap into existing libraries published on NPM.

I don't expect much traction with the launch version and plan to target a specific domain shortly after that. I'm leaning towards a build system where you can capture your dependencies in a visual graph. One of the applications I'd been thinking about was allowing users to build and share games or other applications in a web-editor similar to Scratch.

Devev is also a JS SPA and the client editor uses Electron. The client editor supports more features like multiple windows, editors panes and plugins. Additionally the client can parse new Typescript files but not the SPA. For the SPA to parse TS I'd need to deliver TSC over the web which I won't figure out for V1.

Targeting build systems seems like a great fit as well, since as you pointed out the build DAG is naturally a graph.

When you mentioned games programming, I thought of Dream's visual programming: https://youtu.be/eMRp3QMAkz8?t=773

I love the idea of using typescript types to define visual code atoms. We do a very simple version of that to create our Blockly blocks, e.g. block definition: https://github.com/microsoft/pxt-microbit/blob/master/libs/r... although I'm sure you could take that much farther.

We run TSC in the browser in a worker thread, here's an example, in case that helps: https://github.com/microsoft/pxt/blob/master/pxtcompiler/emi... We use TSC for typechecking and our own typescript compiler for compiling down to ARM assembly.

That being said, our platform is fairly extensible so someone could create an Android Apps target. They'd need to create a new backend to target the JVM probably and some work to link with whatever pre-built Android binaries.

Not affiliated, just also interested in new and emerging easy to use game systems, and this is just the latest in a long line of them I've been playing with ..

Everything I googled would give me results in the Phaser forums and the exercise was on me to figure out which version they were using, which was 100% Phaser 2.

And the API definitely wasn't written for Typescript support. For example, just changing the physics string completely changes the API available which felt like an exercise in obfuscation.

Also found the API so unintuitive that I was trying to repurpose examples to get what I wanted which is always a bad sign to me, like hoping your question appears in an FAQ because the code is too hard to read.

Ended up using https://excaliburjs.com/ which is written in Typescript thus much less guesswork. I really didn't like my experience with Phaser.

I don't know about changes in the last 2 years, haven't used it since then, maybe it's changed for worse but can't imagine