Microsoft MakeCode (PXT): A TypeScript Framework for Building Beginner Coding Editors

What PXT Actually Solves

PXT solves a specific problem: how to give beginners a programming environment that is visual, block-based, and text-based at the same time, without forcing teachers or students to manage two separate tools. The README describes it as a framework for creating special-purpose programming experiences for beginners, focused on computer science education. The underlying language is a subset of TypeScript that deliberately leaves out JavaScript's dynamic features. That restriction is the core of the design: it makes the language predictable enough for static analysis, which in turn lets the tool convert blocks to text and back, and even emit ARM Thumb machine code. The people this is for are not end users. They are the developers who build editors like makecode.microbit.org or arcade.makecode.com. If you are making a coding editor for a new microcontroller, a robotics kit, or an educational game platform, PXT gives you the editor, the converter, and the package manager out of the box.

The Architecture: Blockly, Monaco, and an ARM Thumb Emitter

The README lists four main features, and together they describe the data flow. A user drags blocks in a Blockly-based editor. The framework converts those blocks to a text format, which is the subset of TypeScript. That text can be edited in a Monaco editor, the same component that powers VS Code. The system supports extensibility: you can define new blocks in TypeScript, which means the block palette is not fixed. Then the ARM Thumb machine code emitter turns the TypeScript subset into code for ARM-based microcontrollers. That is a significant piece of machinery. Most block-based editors stop at generating JavaScript or Python. PXT goes further and compiles to native code for a specific instruction set. The README does not say which ARM variants are supported, so you will have to check the documentation. The architecture is not a single editor; it is a toolkit where the editor, the language, and the compiler are tightly coupled. That coupling is what makes the block-to-text conversion reliable, but it also means you cannot swap out the language or the compiler without touching the framework.

Getting It Running: Commands from the README

The build process is straightforward on paper. You need Node, minimum version 8, which is a low bar. From the repository root, run `npm install` and then `npm run build`. After that, install the command line tool globally with `npm install -g pxt`, and also install `gulp` globally with `npm install -g gulp`. The README notes that you only need to do the global installs once. To start a local web server, you run `pxt serve` from within the root of an app target, such as pxt-microbit. That command opens the editor in your default browser. If you are developing against PXT itself, you can run `gulp watch` from the pxt repository to rebuild on changes. There is also `gulp watchCli` for working on the CLI exclusively. A useful flag is `gulp --no-webapps`, which skips building the suite of associated webapps like skillmap and multiplayer, speeding up the build. Linking a local target to your own PXT checkout is done with `pxt link ../pxt` from the target directory. The README warns that if you run `npm i` afterwards, you may need to repeat the link step. That is a concrete operational detail that will matter if you maintain a fork.

A Real Limitation: The TypeScript Subset and Dynamic Features

The most important limitation is stated plainly in the first paragraph: the underlying language is a subset of TypeScript, leaving out JavaScript dynamic features. That means no `eval`, no dynamic property access in the way JavaScript allows, and no arbitrary runtime behavior. For a beginner editor, that is a feature, because it prevents a whole class of confusing errors. But it is also a hard constraint. If your target audience needs to use dynamic JavaScript, or if your curriculum expects students to learn full TypeScript, PXT is the wrong tool. Another limitation is the build complexity. The README shows a multi-step build with global installs of `pxt` and `gulp`, and the webapps are part of the default build. If you only want the editor core, you must remember the `--no-webapps` flag. The project also depends on a specific set of tools, like `svgo` for icon optimization, which is an extra global install. The README does not mention a Docker image or a prebuilt binary, so you are expected to build from source. That is a barrier for a small team that just wants to try out an editor.

The Alternative: Building on Blockly Directly

The obvious alternative is to use Google's Blockly directly, without PXT. Blockly is a library that provides the block editor and the block-to-code generation. The difference in approach is significant. With Blockly, you write your own generators to produce JavaScript, Python, or any language you choose. You also provide your own text editor, your own compiler or interpreter, and your own package manager. PXT bundles all of those. The trade-off is control versus convenience. With Blockly, you can define your own language semantics without being constrained to the TypeScript subset. You can also keep the runtime small if you do not need native code emission. But you lose the integrated converter that PXT provides, and you have to build the project scaffolding yourself. The README makes clear that PXT is not just an editor; it is a programming experience toolkit. If you only need the block editor, Blockly is leaner. If you need the whole experience, PXT gives you more out of the box.

Maintenance and Upgrade Cost

The README gives some hints about the maintenance burden. There are two branch tracks: `master` is the active development branch with v3.* builds, and `v*` is the servicing branch for older builds. That means the project is under active development, and you will need to track releases if you want fixes. The README does not list recent releases, so you cannot see the cadence from this material. The linking process described in the README is a sign of the upgrade cost: if you modify your own instance of PXT and want a target to use it, you run `pxt link ../pxt`, and you may need to repeat that after running `npm i`. That suggests that dependency resolution is not fully automated, and you will have to manage the link manually. The build also requires you to keep `gulp` and `pxt` globally installed, which can cause version conflicts on a shared machine. The license is MIT, which is permissive, but the README includes a trademark section. MICROSOFT, the Microsoft Logo, and MAKECODE are registered trademarks, and their use is restricted by Microsoft's guidelines. That is not a legal constraint on the code itself, but it does mean you cannot name your product MakeCode without checking the trademark policy. The code of conduct is Microsoft's standard one, which is fine for most projects.

Who Should Adopt PXT and Who Should Not

The README lists real editors built on PXT: micro:bit, Arcade, Adafruit, Minecraft, Mindstorms, and Chibitronics. That is evidence that the framework works for a range of hardware and game targets. If you are building an editor for a new microcontroller that is ARM-based, PXT's emitter is a strong reason to choose it. If your target is not ARM, you will need to extend the emitter, which is a serious undertaking. The README does not describe how to do that, so you would need to dig into the source. For a team with TypeScript experience, the learning curve is manageable. For a team that is not comfortable with TypeScript, Node, and a gulp-based build, the cost will be high. The framework is also heavy: it includes a Monaco editor, a Blockly editor, a package manager, and a compiler. If you only need a simple block editor for a web page, this is overkill. The conclusion is that PXT is for organizations that want to build a full educational programming environment, not for individual developers who want a quick block editor. Before you commit, verify that your target hardware is supported by the ARM Thumb emitter, and check the current state of the master branch, since it is the active development branch and the README does not provide a release history.

Editorial conclusion

Adopt PXT if you are building a beginner-focused coding editor for a specific microcontroller or game platform and you are comfortable with TypeScript, Node, and a heavy build toolchain. Do not use it if you need a lightweight editor, want to support dynamic JavaScript, or cannot commit to maintaining a target repository and syncing with PXT's release cadence. Before adopting, verify that your target hardware is supported by the ARM Thumb emitter or that you can extend it, and check the current state of the pxt CLI and the master branch, since the README notes that master is the active development branch with v3.* builds and servicing branches for older versions.

Official sources

1. Official documentation
2. Official README
3. Project repository