Run JavaScript in Python with pwasm

Run JavaScript and Python as WebAssembly inside a Python script with pwasm.

Introduction

30 Second Summary

Trying one line of another programming language can mean installing a pile of extra software. A quick experiment suddenly becomes a setup project.

In this project, you will build a Python script that uses pwasm to run QuickJS and MicroPython as WebAssembly. The script prints each result before comparing its timing with native Python.

What You'll Build

Run your finished script to see a JavaScript answer, a MicroPython message, and a timing table appear from one Python command.

By the end of this project, you'll have:

  • A JavaScript result produced through the QuickJS build bundled with pwasm.
  • A Python result produced through the bundled MicroPython build.
  • A timing comparison that shows the speed difference between both WebAssembly runs and native Python.
  • Secret Mission: An optional challenge to push your skills further.

Are there any prerequisites?

You need Python installed with pip available. You do not need Node or a compiler.

Before We Start

Running code inside WebAssembly starts with a dependable host environment. pwasm requires Python 3.10 or newer.

This step confirms that your command-line tools are ready. It also gives your experiment a dedicated local repository.

In this step, get ready to:
  • Confirm that Python 3.10 or newer includes pip.
  • Confirm that Git is available.
  • Create the local pwasm-experiment repository.
Check Python and pip

Python runs the experiment from your computer. The pip installer adds the package that powers it.

  • Press Cmd+Space on macOS or the Windows key on Windows to open system search.
  • Type Terminal on macOS or PowerShell on Windows.
  • Press Enter to open the terminal.

Your terminal is open. You now have one place to run every command in this project.

macOS

  • Check the installed Python version by running this command:
python3 --version

What Does This Check Do?

The --version option prints the Python version selected by python3. This reveals whether that interpreter meets the package requirement.

Windows

  • Check the installed Python version by running this command:
python --version

What Does This Check Do?

The --version option prints the Python version selected by python. This reveals whether that interpreter meets the package requirement.

✔️ I see version 3.10 or higher

Your Python runtime meets the requirement. You can use it to run the WebAssembly experiment.

ⓧ I see an older Python version

Your current interpreter is below Python 3.10. Install a supported release so the package can load.

  • Visit the official Python downloads page.
  • Download a supported stable release for your operating system.
  • Complete the installer using its default options.
  • Close your current terminal after the installation finishes.
  • Reopen the terminal through system search.
  • Return to the version check above to confirm Python 3.10 or newer.

Using macOS?

macOS can keep its Apple-provided interpreter beside the Python release you install. Use the newer python3 interpreter for this project.

ⓧ Python is not found

Your terminal cannot find a Python interpreter. The official installer supplies Python plus pip.

  • Visit the official Python downloads page.
  • Download a supported stable release for your operating system.
  • Complete the installer using its default options.
  • Close your current terminal after the installation finishes.
  • Reopen the terminal through system search.
  • Return to the version check above to confirm Python 3.10 or newer.

A working Python installation normally includes pip. The next check confirms that the package installer belongs to the same interpreter.

macOS

  • Check pip through your Python interpreter by running this command:
python3 -m pip --version

Why Run pip Through Python?

The -m option asks this exact Python interpreter to run its pip module. This avoids confusion when several Python installations share one computer.

Windows

  • Check pip through your Python interpreter by running this command:
python -m pip --version

Why Run pip Through Python?

The -m option asks this exact Python interpreter to run its pip module. This avoids confusion when several Python installations share one computer.

You should see a pip version plus the location of its Python installation. That confirms your package installer is ready.

pip Is Missing?

Re-run the official Python installer if the command reports that the pip module is unavailable. The standard Python installers include it.

If the command still fails, ask for help with the exact output: Help me connect pip to my supported Python installation.

Check Git

Git records snapshots of your project as it changes. Confirming it now prepares the folder for the commit you create later.

  • Check whether the Git command is available by running this command:
git --version

What Does This Check Do?

The --version option prints the installed Git version. A version number confirms that your terminal can use Git.

✔️ I see a Git version

Git can track each stage of your experiment. Your repository tools are ready.

ⓧ Command not found

Git needs to be installed before you create the repository. Choose the instructions for your operating system.

macOS

  • Accept the command-line tools installation prompt that appears after the version check.
  • Wait for the installation to finish.
  • Close your current terminal.
  • Reopen the terminal through system search.
  • Return to the Git version check above.

Windows

  • Visit the official Git for Windows download page.
  • Download the installer.
  • Complete the installer using its default options.
  • Close your current terminal after the installation finishes.
  • Reopen the terminal through system search.
  • Return to the Git version check above.

Git Still Is Not Found?

A terminal opened before the installation may not know the updated command path. Close every terminal window before opening a fresh one.

If the new terminal still cannot find Git, ask for help: Help me make Git available in my terminal.

Initialize Git

A dedicated project folder keeps the experiment separate from your other files. Initializing Git inside that folder creates the hidden metadata used to track future commits.

macOS

  • Move to your Desktop by running this command:
cd ~/Desktop

What Does This Command Do?

The cd command changes the terminal location. ~/Desktop points to the Desktop inside your home folder.

  • Create the pwasm-experiment folder and move into it by running these commands:
mkdir pwasm-experiment
cd pwasm-experiment
pwd

What Do These Commands Do?

  • The mkdir command creates the project folder on your Desktop.
  • The cd command moves the terminal into that folder.
  • The pwd command prints the folder currently used by the terminal.
  • Confirm that the printed path ends with pwasm-experiment.

Folder Already Exists?

The folder name is already in use if mkdir reports an existing file or directory. Remove the old practice folder only if you no longer need its contents.

For help checking what is inside first, ask: Help me inspect my existing pwasm-experiment folder safely.

Windows

  • Move to your Desktop by running this command:
Set-Location -Path ~/Desktop -PassThru

What Does This Command Do?

The Set-Location command changes the PowerShell location. The -PassThru option prints the new Desktop path.

  • Create the pwasm-experiment folder and move into it by running these commands:
New-Item -ItemType "Directory" -Path "pwasm-experiment"
Set-Location -Path "pwasm-experiment" -PassThru

What Do These Commands Do?

  • The New-Item command creates the project folder on your Desktop.
  • The Set-Location command moves PowerShell into that folder.
  • The -PassThru option prints the folder now used by PowerShell.
  • Confirm that the printed path ends with pwasm-experiment.

Folder Already Exists?

The folder name is already in use if New-Item reports an existing item. Remove the old practice folder only if you no longer need its contents.

For help checking what is inside first, ask: Help me inspect my existing pwasm-experiment folder safely.

Before you run the next command, do you think Git will recognize this empty folder as a repository?

  • Initialize the local Git repository by running this command:
git init

What Does This Command Do?

The git init command creates a hidden .git directory inside pwasm-experiment. That directory stores the repository structure used for version history.

Git reports that it initialized an empty repository in the local project directory. That is the foundation your future commit needs.

Repository Initialization Failed?

Check that your terminal path ends with pwasm-experiment. A permission error means your account cannot write to the selected folder.

If the command still fails, ask for help with the output: Help me initialize this local Git repository.

Before the final check, what do you expect Git to report for a repository with no files or commits?

  • Verify that the terminal is inside the initialized repository by running this command:
git status

What Does This Check Prove?

The git status command reads the repository in the current folder. A branch status with no commits confirms that Git recognizes the new repository.

You now have an initialized empty Git repository. Your terminal remains open inside its local project directory.

Your local workspace is ready. Next up, you install the pwasm pre-release and confirm its version.

Install pwasm

Your local Git repository is ready for its first dependency. The active Python environment still needs pwasm to execute WebAssembly modules.

Version 0.2a0 bundles the guest engines used later in this project. This step installs that alpha release from PyPI.

In this step, get ready to:
  • Install the pwasm 0.2a0 pre-release in the active Python environment.
  • Print the installed package metadata to verify the version.
Install the pwasm pre-release

An exact version pin asks pip for a specific release. Here it selects the alpha wheel required for the project.

  • Use the active Python interpreter for the installation by running this command:
python -m pip install pwasm==0.2a0

What does this command do?

  • The module invocation runs pip through the active Python interpreter.
  • The pwasm==0.2a0 requirement requests one exact distribution release from PyPI.

Good progress. The pwasm wheel is now available to the Python interpreter you will use throughout the project.

Installation not completing?

  • Confirm that the terminal still uses your active Python environment.
  • Check that your internet connection can reach PyPI.
  • Help me diagnose my pwasm installation.
Verify the installed version

Installed package metadata identifies the release available to your current interpreter. The version field gives you a direct checkpoint before you begin using the engine.

Before you check, do you expect the active environment to report the alpha you requested or a different installation?

  • Print the installed pwasm metadata by running this command:
python -m pip show pwasm

What does this command show?

The output lists metadata for the pwasm distribution installed in the active environment. The Version field is the checkpoint for this step.

You will see the Version field report 0.2a0.

That is your first dependency locked in. The active environment now has the exact pwasm alpha required for the project.

Version missing or different?

  • Return to the installation substep if no package metadata appears.
  • Repeat the pinned installation if the Version field shows a different release.
  • Help me verify my pwasm environment.

Your WebAssembly engine is installed. Next, you will use it to run your first JavaScript expression inside Python.

Run JavaScript with QuickJS

Your pwasm installation is verified. It can now host a JavaScript guest inside your Python process.

QuickJS is bundled as a WebAssembly build inside pwasm. This lets your Python script evaluate JavaScript without Node or a compiler.

In this step, get ready to:
  • Create run_wasm_engines.py for the QuickJS experiment.
  • Evaluate a one-line JavaScript expression through QuickJS.
  • Confirm the decoded result in your terminal.
Build the QuickJS runner

QuickJS from pwasm.guests wraps the bundled .wasm file. Creating js loads that guest into the Python process.

  • Create run_wasm_engines.py inside the local project directory by pasting the code below into a new file with your text editor:
from pwasm.guests import QuickJS

# Load the bundled QuickJS WebAssembly guest with a 32 MB memory cap
js = QuickJS(max_memory=32 * 1024 * 1024)

# Evaluate the JavaScript expression inside the guest
# Print the decoded result in Python
print(js.eval("[1, 2, 3].map(x => x * 2)"))  # [2, 4, 6]

What does this code do?

  • QuickJS selects the JavaScript guest bundled with the pwasm wheel.
  • max_memory=32 * 1024 * 1024 caps the guest memory at 32 MB.
  • js.eval() evaluates the expression inside QuickJS. It returns the result decoded from JSON.
  • Save run_wasm_engines.py in the local project directory.
Run the JavaScript expression

QuickJS evaluates the array operation inside the bundled WebAssembly guest. The returned list crosses back into Python for printing.

Before you run the script, pause to predict the values produced after x * 2 is applied to every number.

  • Run run_wasm_engines.py with Python by using this command:
python run_wasm_engines.py

What should I see?

You should see [2, 4, 6] in the terminal. Your JavaScript expression has now run inside QuickJS.

The decoded result has returned to your Python script. That completes your first cross-language WebAssembly run.

No JavaScript result?

  • Return to the active Python environment from earlier if Python reports that it cannot import pwasm.
  • Compare the import path with pwasm.guests if the script stops at the first line.
  • Compare the expression with [1, 2, 3].map(x => x * 2) if QuickJS reports a JavaScript problem.

Help me diagnose my QuickJS run.

The finished file is available below for comparison.

✔️ Awesome, I've got everything!

Your saved script now loads QuickJS. It also prints the decoded JavaScript result.

ⓧ I'd like to double check the full code

from pwasm.guests import QuickJS

# Load the bundled QuickJS WebAssembly guest with a 32 MB memory cap
js = QuickJS(max_memory=32 * 1024 * 1024)

# Evaluate the JavaScript expression inside the guest
# Print the decoded result in Python
print(js.eval("[1, 2, 3].map(x => x * 2)"))  # [2, 4, 6]

This reference shows the complete saved file for this step.

Your Python script can now run JavaScript through a bundled WebAssembly engine. Next, you will add a MicroPython guest to the same experiment.

Run Python with MicroPython

Your QuickJS result proves that pwasm can run JavaScript inside your Python script. The script currently demonstrates one bundled guest.

MicroPython gives the same script a Python interpreter compiled to WebAssembly. You will load that guest inside the existing script.

In this step, get ready to:
  • Extend the existing guest import with MicroPython.
  • Execute a short Python snippet through MicroPython.
  • Verify the new output beside the JavaScript result.
Import the MicroPython guest

Each bundled interpreter has a guest class in pwasm.guests. Importing the MicroPython class makes it available beside the existing QuickJS class.

  • Open run_wasm_engines.py in the editor you used earlier.
  • Find this existing import line:
from pwasm.guests import QuickJS

Why Change This Import?

The existing line exposes the QuickJS guest class to your script. The next version also exposes MicroPython.

  • Replace the existing import with this expanded version:
from pwasm.guests import MicroPython, QuickJS

What Changed?

This import keeps QuickJS available. It also gives the script access to the bundled MicroPython guest.

  • Save run_wasm_engines.py.

Before you repeat the script-running command, consider whether the expanded import should change the JavaScript result.

  • Repeat the script-running command from the previous step.

You should still see [2, 4, 6]. Your JavaScript path still works with the expanded import.

Did the Existing Result Stop Working?

  • Check that the import line matches the replacement exactly.
  • Confirm that you kept the existing QuickJS name in the import.
  • Ask for help with the import change.
Run a Python snippet in WebAssembly

The MicroPython guest accepts Python source code as text. Its execution method returns everything that the snippet prints.

  • Place your cursor below the existing QuickJS result line in run_wasm_engines.py.
  • Add the MicroPython guest by copying this code:
mp = MicroPython(timeout=2.0)
print(mp.exec("print([x * x for x in range(5)])"))  # [0, 1, 4, 9, 16]

What Does This Code Do?

  • The MicroPython(timeout=2.0) call creates the bundled Python guest with a wall-clock limit.
  • The exec() method sends the list comprehension to the guest interpreter.
  • The outer print() call displays the text returned by MicroPython.
  • Save run_wasm_engines.py.

Before you run the script, picture the two result lines you expect the terminal to show.

  • Repeat the script-running command from the previous step.

You should see [0, 1, 4, 9, 16] below the JavaScript result. That is both bundled guests working from one Python script.

Missing the MicroPython Output?

  • Check that the two new lines sit below the existing QuickJS result code.
  • Confirm that MicroPython appears in the import at the top of run_wasm_engines.py.
  • Ask for help with the MicroPython guest.

✔️ Awesome, I've got everything!

Your saved script now runs JavaScript through QuickJS and Python through MicroPython.

ⓧ I'd like to double check the full code

from pwasm.guests import MicroPython, QuickJS

js = QuickJS(max_memory=32 * 1024 * 1024)
print(js.eval("[1, 2, 3].map(x => x * 2)"))  # [2, 4, 6]

mp = MicroPython(timeout=2.0)
print(mp.exec("print([x * x for x in range(5)])"))  # [0, 1, 4, 9, 16]

Both bundled guests now run from one script. Next, you will measure the speed cost of each execution path.

Compare Execution Times

Your script already runs QuickJS through pwasm. It also runs MicroPython as a WebAssembly guest.

Performance remains the missing piece. This step measures both guest runs against an equivalent native Python calculation.

In this step, get ready to:
  • Measure the QuickJS WebAssembly run.
  • Measure the MicroPython WebAssembly run.
  • Compare both timings with native Python.
Measure each execution path

A performance counter measures short durations with a high-resolution clock. The elapsed time comes from subtracting one perf_counter() reading from the next.

  • Switch back to run_wasm_engines.py in the editor from earlier.
  • Select the existing file contents.
  • Replace the selected code with the cumulative script below:
from time import perf_counter
from pwasm.guests import MicroPython, QuickJS

# Use equivalent workloads that each total the integers from 0 to 999.
javascript_code = "Array.from({ length: 1000 }, (_, i) => i).reduce((total, value) => total + value, 0)"
micropython_code = "print(sum(range(1000)))"

# Measure each WebAssembly guest around its execution call.
quickjs = QuickJS()
start = perf_counter()
javascript_result = quickjs.eval(javascript_code)
quickjs_seconds = perf_counter() - start
micropython = MicroPython()
start = perf_counter()
micropython_output = micropython.exec(micropython_code)
micropython_seconds = perf_counter() - start

# Measure the equivalent calculation in native Python.
start = perf_counter()
native_result = sum(range(1000))
native_seconds = perf_counter() - start

# Calculate each guest's slowdown relative to native Python.
quickjs_slowdown = quickjs_seconds / native_seconds
micropython_slowdown = micropython_seconds / native_seconds

# Print one summary line for each execution path.
print(f"QuickJS: {javascript_result} in {quickjs_seconds:.6f}s ({quickjs_slowdown:.1f}x native)")
print(f"MicroPython: {micropython_output.strip()} in {micropython_seconds:.6f}s ({micropython_slowdown:.1f}x native)")
print(f"Native Python: {native_result} in {native_seconds:.6f}s")

What does this code measure?

  • The first pair of perf_counter() readings measures the QuickJS evaluation.
  • The second pair measures the MicroPython execution.
  • The native calculation provides the baseline.
  • Each slowdown value divides a WebAssembly duration by the native duration.
  • Save run_wasm_engines.py.

Expect the first comparison to take a few seconds while pwasm starts both guests.

  • Predict which execution path will be fastest before you run the script.
  • Run the saved script from the terminal by entering:
python run_wasm_engines.py

What should I see?

You should see three timing lines. Every result should be 499500.

The QuickJS line shows a slowdown ratio. The MicroPython line shows its own ratio against native Python.

That result gives you the missing evidence. Your script now measures the performance cost of both WebAssembly guests.

Missing a timing result?

  • Confirm that the terminal still uses the Python environment from the installation step if the pwasm import fails.
  • Check that every start = perf_counter() line appears before its matching execution call.
  • Use this debugging prompt if the script stops before printing all three lines.

✔️ Awesome, I've got everything!

Your benchmark is saved in run_wasm_engines.py.

ⓧ I'd like to double check the full code

from time import perf_counter
from pwasm.guests import MicroPython, QuickJS

# Use equivalent workloads that each total the integers from 0 to 999.
javascript_code = "Array.from({ length: 1000 }, (_, i) => i).reduce((total, value) => total + value, 0)"
micropython_code = "print(sum(range(1000)))"

# Measure each WebAssembly guest around its execution call.
quickjs = QuickJS()
start = perf_counter()
javascript_result = quickjs.eval(javascript_code)
quickjs_seconds = perf_counter() - start
micropython = MicroPython()
start = perf_counter()
micropython_output = micropython.exec(micropython_code)
micropython_seconds = perf_counter() - start

# Measure the equivalent calculation in native Python.
start = perf_counter()
native_result = sum(range(1000))
native_seconds = perf_counter() - start

# Calculate each guest's slowdown relative to native Python.
quickjs_slowdown = quickjs_seconds / native_seconds
micropython_slowdown = micropython_seconds / native_seconds

# Print one summary line for each execution path.
print(f"QuickJS: {javascript_result} in {quickjs_seconds:.6f}s ({quickjs_slowdown:.1f}x native)")
print(f"MicroPython: {micropython_output.strip()} in {micropython_seconds:.6f}s ({micropython_slowdown:.1f}x native)")
print(f"Native Python: {native_result} in {native_seconds:.6f}s")
Interpret the slowdown ratios

The absolute timings depend on your computer. The ratios reveal the extra work required to execute the same calculation through pwasm.

  • Compare the QuickJS slowdown value with the native Python line.
  • Compare the MicroPython slowdown value with the native Python line.
  • Confirm that all three result values are 499500.

You should see native Python finish fastest. The two WebAssembly timings make the performance tradeoff visible.

Your benchmark now exposes the speed tradeoff. Next up, you will turn these results into a table inside the script.

Save and Commit Your Results

Your pwasm experiment now runs QuickJS and MicroPython through WebAssembly. The timing comparison makes the performance cost visible.

This final step turns that working experiment into a durable snapshot. You will confirm the results table before recording the completed script in Git.

In this step, get ready to:
  • Verify the saved script still prints the complete results table.
  • Stage the completed experiment script.
  • Create a commit for the finished experiment.
Confirm the finished experiment

A final run checks the exact file that you are about to commit. It also gives you one last view of the engine outputs and their timing gap.

  • Return to run_wasm_engines.py in the editor you used earlier.
  • Press Cmd+S (macOS) or Ctrl+S (Windows) to save it.

Before you run the script, which execution do you expect to finish fastest?

  • Run the saved experiment from the terminal you used earlier by running this command:
python run_wasm_engines.py

What does this command prove?

  • Python executes the saved run_wasm_engines.py file from your repository.
  • The snippet outputs confirm that both bundled engines still execute correctly.
  • The results table confirms that all three timing measurements remain intact.

You should see the JavaScript result and the MicroPython output. Below them, you should see a table comparing QuickJS WebAssembly, MicroPython WebAssembly, and native Python timings.

Script no longer runs?

Check that the terminal still uses the active Python environment from earlier. Confirm that the terminal is still inside the local repository containing run_wasm_engines.py.

If the table is missing, confirm that you saved the file before running it. Help me diagnose why my pwasm results table is missing.

Your saved script now reproduces the complete experiment. That is the result worth preserving.

Prepare the repository snapshot

Git uses a staging area to select the files included in a commit. You will stage only run_wasm_engines.py so the snapshot stays focused.

  • Inspect the repository changes by running this command:
git status

What does this command show?

The command compares your current files with the repository history. It shows which files are ready to stage.

You should see run_wasm_engines.py listed as a repository change.

  • Stage the completed script by running this command:
git add run_wasm_engines.py

What does staging do?

Staging selects the current contents of run_wasm_engines.py for the next commit. Git can now record this exact version of the experiment.

  • Confirm that the script is staged by running this command:
git status

What changed in the status?

The script should now appear in the group of changes ready for a commit. This confirms that the saved file is part of the upcoming snapshot.

  • Create the repository snapshot by running this command:
git commit -m "Save pwasm experiment results"

What does this command record?

The commit stores the staged version of your script in the repository history. The message describes the purpose of that snapshot.

The terminal should print a commit summary with a new identifier. It should also report the recorded file change.

Commit did not complete?

  • Follow the configuration guidance shown in the terminal if Git requests author details.
  • Retry the commit after saving those details.
  • Ask for help with the commit output by selecting Help me fix this Git commit.

That is the snapshot secured. Your finished experiment now has a point in history you can return to.

Inspect the repository history

The latest commit entry is the clearest proof that the snapshot exists. A compact history view shows its identifier beside your commit message.

Before you check, what commit message do you expect to see beside the newest identifier?

  • Show the newest commit on one line by running this command:
git log -1 --oneline

How does this verify the commit?

The command reads the newest entry from the repository history. The compact format places its short identifier beside the commit message.

You should see one line containing a short commit identifier followed by Save pwasm experiment results.

Your pwasm experiment is now saved as a reproducible script and recorded in your own Git repository. You can rerun the results or return to this exact snapshot whenever you need it.

Secret mission

Stress-Test the Benchmark

One timing table can be lucky or unlucky. Run the benchmark five times to test its consistency. Compare the spread before writing a verdict about pwasm.

Clean Up Your Resources

Clean Up Your Resources

This pwasm experiment runs locally, so it has no ongoing service costs. Choose to keep the local project directory, leave it untouched for later, or delete it.

Resources you used:

  • The completed run_wasm_engines.py script with the timing results table.
  • Your local Git repository that stores the experiment's commit history.

Keep everything running

No action is needed while you are still using the experiment. Your local files have no ongoing cost.

  • Keep the local project directory in its current location.
  • Leave pwasm installed in the active Python environment.
  • Use the committed script whenever you want to repeat the timing comparison.

Pause - I'll come back to this later

The script leaves no engine process running after it finishes. Pausing means keeping the local project directory for another session.

  • Close the terminal window from earlier.
  • Leave the local project directory unchanged.
  • Return to the same directory when you are ready to continue experimenting.

Delete - I don't want to use this again

Deletion clears the local artifacts when you no longer need the experiment.

Protect Anything You Want to Keep

Deleting the local project directory removes the script plus its local commit history. This is safe when you no longer need either resource.

  • Copy run_wasm_engines.py outside the local project directory if you want to preserve the script.

macOS

  • Close the terminal window from earlier.
  • Press Cmd+Space to open macOS search.
  • Type Finder into the search field.
  • Press Enter to open Finder.
  • Search Finder for run_wasm_engines.py.
  • Open the folder containing the matching file.

The matching file sits inside the local project directory that also contains the repository history.

  • Move to the enclosing folder in Finder.
  • Drag the local project directory into Trash.
  • Empty Trash.

You should no longer see the local project directory in its previous location. That is your local cleanup complete.

Windows

  • Close the terminal window from earlier.
  • Press the Windows key to open Windows search.
  • Type File Explorer into the search field.
  • Press Enter to open File Explorer.
  • Search File Explorer for run_wasm_engines.py.
  • Open the folder containing the matching file.

The matching file sits inside the local project directory that also contains the repository history.

  • Move to the parent folder in File Explorer.
  • Select the local project directory.
  • Press the Delete key to move the directory into Recycle Bin.
  • Empty Recycle Bin.

You should no longer see the local project directory in its previous location. That is your local cleanup complete.

Nice Work!

Nice Work!

You made it! Your pwasm experiment now runs two languages through WebAssembly inside Python. You also committed the finished script to your own repository.

You've learned how to:

  • Install the pwasm pre-release from PyPI. You confirmed the installed version before using the engine.
  • Execute JavaScript through QuickJS and Python through MicroPython. Both runtimes used the WebAssembly builds bundled with pwasm.
  • Measure the WebAssembly performance cost against native Python. Your results table shows the timings and relative slowdown for each run.
  • Secret Mission: Completed an optional challenge that pushed your WebAssembly experimentation further.

Ready to quiz yourself?