When debugging JavaScript in the browser, it’s easy to look at the Network tab, see your script loading correctly, and assume everything should work.
But loading ≠ executing.
Network tab: “Is the file there?”
The Network panel only answers one question: Did the browser successfully fetch the file?
A JS file appearing in Network means:
- The path is correct
- The server returned 200 OK
- The browser downloaded it
It does not mean the code ran successfully.
Console: “Did the code survive reality?”
Runtime errors only appear in the Console.
Errors like:
Uncaught TypeError: Cannot read properties of null
Uncaught TypeError: Cannot read properties of null (reading 'getContext')
Almost always mean:
- The DOM element doesn’t exist yet
- The script ran before the page finished loading
- The element ID is wrong
The classic canvas mistake
This error:
Cannot read properties of null (reading 'getContext')
Means:
document.getElementById("canvas") === null
The fix is not magic — it’s timing.
Two correct patterns
// Option 1: Place script at bottom of HTML
<script src="soroban.js"></script>
// Option 2: Wait for DOM
document.addEventListener("DOMContentLoaded", () => {
const canvas = document.getElementById("canvas");
});
Takeaway
- Network tab = file delivery
- Console = code execution
- Green Network ≠ working JavaScript
Once you internalize this distinction, debugging becomes calmer, faster, and much more predictable.
This lesson was learned while porting a C# Soroban app to the web — a reminder that browsers are strict, but fair.