The GitHub Blocks experiment will soon be open to all users, according to senior director of research Idan Gazit, but whether it becomes a generally available product is not yet decided.
“We’re likely to drop the need for a waitlist soon,” said Gazit on the GitHub Next Discord, a public forum for the project. “I can’t share a specific timeline, but … order of weeks not months.” That said, there are no plans currently to support GitHub Enterprise, the on-premises deployment of GitHub. Gazit also said that “we can’t offer any timeline or guarantee that Blocks turns into a product. The purpose of this experiment is ultimately to prove the value of this approach so that GitHub’s product engineering decides to turn it into a part of github.com, as well as other experiences like VS Code, and general embedding on the web.”
Users admitted to the experiment can develop blocks locally. Blocks are React components (with templates for Svelte and Vue also on offer) that interact with content in a GitHub repository. However they can only be viewed via a special GitHub site, which embeds the development server.
The Block concept is a simple one. It is a set of JavaScript files that take input from a repository (either a file or folder), along with hooks into the GitHub API to enable actions such as writing back new commits. What that JavaScript does is down to the developer, with examples being rendering markup such as SVG files as images, rich presentation of CSS files with actual colors and styles, display of data from JSON or CSV files in smart tables, editable diagrams and more. Blocks can also display visualizations of repository activity. One developer is working on a syntax highlighter for a programming language they are designing. The ability of Blocks to present code visually may make them useful for presenting aspects of an application under construction to potential users.
Blocks might also have a life outside GitHub, hence Gazit’s comment about Visual Studio Code. Many of the features that would be useful on GitHub would also be useful in the local editor.
In order for Blocks to become a full product, the ability to run them would need to be built into the production GitHub site, and that represents significant work. GitHub is also security-critical, entrusted with the code for millions of business applications, so that is another factor. Extending the capabilities of blocks with things like access to securely-stored secrets would be good for functionality, but also makes them potentially more vulnerable to mis-use. Currently blocks run in a sandboxed iFrame in order to support untrusted code.
The experiment though does raise the question of to what extent a code repository should be able to run code as well as managing it. Blurring that boundary has plenty of potential, but maintaining a clean separation between those functions also has value.