Introducing the Motoko Playground, an Online Development Environment for the Internet Computer
The Motoko Playground allows users to build and deploy canister smart contracts directly within a web browser.
By Yan Chen, Senior Software Engineer | DFINITY
To simplify the experience of developers onboarding to the Internet Computer, the DFINITY Foundation’s languages team announces the open-source release of the Motoko Playground, an integrated development environment (IDE) that runs on the Internet Computer blockchain.
Using Motoko, a programming language that is designed to seamlessly support the programming model of the Internet Computer, the Motoko Playground allows users to build and deploy canister smart contracts directly within a web browser, without needing to download the DFINITY Canister SDK or set up a wallet. Because developers don’t need to set up their own development environment, this full in-browser experience enables anyone to explore and learn Motoko while experimenting with programming on the Internet Computer from anywhere.
Getting started with the Motoko Playground
Upon entering the dapp, you can choose what project you want to work with and deploy to the Internet Computer. Following below is an example workflow of using the Motoko Playground.
Step #1: Choose an example project.
To help new developers quickly get started, several Motoko projects are pre-selected from the DFINITY examples repo, such as counter, phone book, random maze, and publisher/subscriber service. You can also import any Motoko code from Github.
Let’s say that the Counter example is chosen from the above list. Under the “Main.mo” link in the navigation, you can view the code.
Step #2: After choosing a project, click the “Deploy” button in the upper right corner to build and deploy the canister on the Internet Computer.
After clicking “Deploy,” specify the name of the canister you want to deploy. In this case, the name of the canister you would want to deploy is “Main.” The deployment takes several seconds, as it needs to fetch a free canister ID from the Internet Computer and install the compiled WebAssembly (Wasm) module.
Step #3: After the canister has been deployed, the Candid UI on the right-hand side can be used to test out the code.
Using the Candid UI, you can communicate with the canister through the browser — you can query the initial value, increment the counter, and so on. (If you prefer, you can also use the command-line interface tools, such as dfx or ic-repl, to interact with the canister.)
Step #4: If you want to make any changes to the code, you can do so in the editor. For example, below we have changed the method to get2().
Step #5: To re-deploy, press the “Deploy” button again. Because the system already knows that you have a canister named “Main,” you must specify whether or not you want to upgrade the existing canister or install a new canister entirely. With the below example, we will upgrade the existing canister.
Step #6: Because the counter is in the stable memory, after the upgrade, when you call the new get2 method, it will return the counter from last time (instead of 0) as an initial value.
Step #7: The Motoko playground supports installation arguments. In the below example, you can add an actor class for the counter.
Step #8: When you try to deploy your canister, the system knows that there is an installation argument and will ask for the starting value of the counter. In the example, the starting value is now 42, and you can reinstall the canister.
Step #9: Now, once you query the initial value, the counter will return a value of 42, as you had specified during the deployment.
For large projects, developers usually need to use third-party Motoko libraries. The Motoko Playground supports the vessel package set, which is a set of community-maintained Motoko libraries. You can import these libraries, such as parsing, SHA256, and various data structure libraries, by clicking the “+” button in the packages section in the left column.
The Motoko Playground supports the same features as your local development environment, such as inter-canister calls, canister upgrades, installing actor class with initialization arguments, and third-party libraries. As an interesting exercise, developers are encouraged to import the CanCan repository, add the “sequence” library from the package section, and build the back-end canister in the Motoko Playground all within a web browser.
Besides the standalone version of the Motoko Playground, there is also an embedded version that is used in the Motoko language manual. It is a lightweight version of the Motoko Playground where users can interactively change the code in the documentation and run (interpret) the code instantly in the browser without needing to install the code on the Internet Computer.
How the Motoko Playground works
All of the source code for the Motoko Playground is now public. A developer going through the code will find a full-stack web dapp with a JavaScript front end and a back-end canister that manages free cycles that is written in both Motoko and Rust.
In contrast to most online IDEs, the Motoko compiler is hosted in the front end, thanks to the js-of-ocaml compiler. This automatically solves security and scalability concerns, because the compiler is run in the user’s browser instead of a remote server. Concretely, the front end consists of the following components:
- A Motoko compiler produced by js-of-ocaml, running in a web worker.
- A Monaco (VSCode) editor that supports Motoko syntax highlighting and validation.
- A Vessel package manager that loads third-party libraries from the vessel package set.
- A deploy module that integrates canister install/upgrade, actor class, and Candid UI.
- A code import module that allows importing any Motoko code from Github.
Free cycles and the back end
To support developer adoption, DFINITY is supplying free cycles for canisters deployed from the Motoko Playground, so that new users do not have to set up a cycle wallet to explore Motoko and the Internet Computer.
The back-end canister is written in Motoko and manages the free cycles that are used by the deployed canisters. To ensure the fair use of these free cycles, there are some restrictions on the deployed canisters: each canister has an initial cycle balance of 0.5T, and can only run for 10 minutes. Cycle transfers across canisters are also not allowed.
Concretely, when the front end asks for a new canister, the back end finds a free canister in its canister pool, tops up its cycles, and sets the expiration duration of this canister. After the expiration time, the back end can give this canister to other users requesting for deployment. To prevent a single person from occupying too many canisters, a proof of work is required when the user is requesting for a new canister.
To ensure resource fairness, we want to avoid users transferring large amounts of cycles to their own canisters. For example, one can easily transfer all of the cycles available in the playground-deployed canister to a target canister by calling the deposit_cycles method in the management canister. To prevent this attack, we inspect all of the submitted Wasm modules and remove the cycle transfer instructions at the Wasm level. Since Motoko doesn’t have a Wasm parsing library for now, a Rust canister is used to achieve this goal. Each time the Motoko back end receives an install request, it will forward the Wasm module to the Rust canister for inspection. This is actually an interesting pattern that mimics FFI support in Motoko.
In the future, these restrictions will be relaxed when users provide their own wallets for deployment, which enables more advanced use cases.
We plan on adding many more features to make the Motoko Playground a full-featured web IDE for the Internet Computer. Community contributions are highly welcomed!
Meanwhile, we hope you enjoy conveniently exploring Motoko, the native language of the Internet Computer, directly within a web browser without having to download the SDK. Interested developers are also encouraged to review the open-sourced code of the Motoko Playground.
____
