Motoko Playground

With the help of the Motoko Playground, developers can seamlessly test, build, and deploy their canister smart contracts to the Internet Computer – directly from within their web browser.

The playground utilizes the Motoko programming language and allows developers to build and deploy canisters without the need for the DFINITY Canister SDK or a wallet. As such, it provides a tool for developers that helps them to explore the Internet Computer and Motoko without having to set up their own development environment.

To get started, simply navigate to the playground dApp and select the type of project would like to work on. You can choose between a variety of example projects but you can also import your own project from Github. The following outlines an example workflow:

Upon entering the dApp, the UI will ask you to choose an example project. You can find a list of sample projects selected from DFINITY’s example repo. These examples include counter, calculator, Hello example, random maze, phonebook, as well as Super Heroes. You can also select a new Motoko project without any existing code.

For this walk-through, let us choose the Counter example from the list. You can view the code of the example project in the Main.mo file located in the navigation. This is also the name of the canister, in this case Main.

In the next step, you can build and deploy the Counter canister on the Internet Computer by clicking the Deploy button. The interface will then ask you to specify the canister name you want to deploy. In the case of our Counter example, the canister you want to deploy is named Main.

Once deployed, you can test that canister’s code with the Candid UI. Candid allows you to communicate with the canister via your web browser. It allows you to query the initial value, increase the counter, etc. Alternatively, you can also interact with your canister through command-line interface tools (like dfx or ic-repl).

You can make changes to your code with the playground editor. In the example below, we are changing the get() method to get2():

Once you are finished editing, simply click on Deploy to redeploy the canister. The UI will then let you choose between installing a new canister or upgrading the existing one. For the purpose of our example, upgrading the existing canister is sufficient.

The playground gives you the option to add installation arguments. In our example, we are going to add an actor class to the playground counter:

In order to update the canister, we are going to redeploy it again. The system will now ask you for the starting value of the counter because of the installation argument. You can select the starting value of your choice, for example 42. Click on Install to confirm.

Larger projects require developers to use a third-party library. The vessel package set is supported by the Motoko Playground. It is a set of different Motoko libraries maintained by the community. These libraries include parsing, SHA256, as well as data structure libraries and can be imported via the + button in the packages section.

Supported by the playground are the same features as in a local development environment. These features include:

An embedded lightweight version of the Motoko Playground is used in the Motoko language manual. The lightweight version allows users to interactively change the featured code of the documentation and to run it instantly from within their web browser.

The source code of the playground can be found on GitHub. It consists of a full-stack dApp that includes a JavaScript front end as well as a backend canister for managing free cycles. The playground is available in the two programming languages Motoko and Rust.

The compiler runs directly in the user’s browser and not on a remote server. This is because the Motoko compiler is being hosted on the front end with the help of the js-of-ocaml compiler. In doing so, security and scalability concerns are automatically solved.

The front end of the playground consists of these components:

The Motoko Playground is powered by free cycles so that developers new to the Internet Computer can explore the ecosystem without having to set up a cycle wallet.

The back-end canister for managing the free cycles used by deployed canisters is written in Motoko. Three restrictions help to ensure that the free cycles are fairly used and distributed:

Let’s have a look at the process when a new canister is requested by the front end:

Users are unable to transfer large cycle amounts to their own canisters. This is enforced by inspecting submitted WebAssembly modules and removing cycle transfers at the Wasm level. This is accomplished by using a Rust canister. Every time a install request is received by the Motoko back and, the Wasm module will be forwarded to the Rust canister for further inspection.